[GitHub] [daffodil-vscode] Shanedell opened a new issue, #270: PR Request VSIX Build and Upload

[GitBox <gi...@apache.org>]

Shanedell opened a new issue, #270:
URL: https://github.com/apache/daffodil-vscode/issues/270

   @stevedlawrence @mbeckerle How would you guys feel about something like this?
   
   So how I imagine this works is:
   
   - Add another job to the CI
   - This job will:
     - Build the VSIX file
     - Upload to GitHub action as an artifact for the job
       - Example of this is at [omega-edit job artifacts](https://github.com/ctc-oss/omega-edit/actions/runs/2922387566)
   
   I believe this would be a nice to have when it comes to checking work of a PR. As this should allow for the checkers to not have to pull down the code and build it themselves, instead they download the VSIX and install it to test. In reality steps would be:
   
   - Download VSIX file from job artifacts
   - Uninstall extension (only if installed)
   - Install extension via VSIX file, `code --install-extension /FULL/PATH/TO/FILE.vsix`
   - Reload VS Code
   - Test
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [daffodil-vscode] mbeckerle commented on issue #270: PR Request VSIX Build and Upload

[GitBox <gi...@apache.org>]

mbeckerle commented on issue #270:
URL: https://github.com/apache/daffodil-vscode/issues/270#issuecomment-1232844532

   re: desirablility of not having to pull down and build .... I actually want to build from source, even if it takes a few minutes, except when testing out a release artifact. I want to be able to permute the code rebuild and see the change in effect. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [daffodil-vscode] Shanedell commented on issue #270: PR Request VSIX Build and Upload

[GitBox <gi...@apache.org>]

Shanedell commented on issue #270:
URL: https://github.com/apache/daffodil-vscode/issues/270#issuecomment-1227532375

   @stevedlawrence I agree with your automated test infrastructure comment. I do have a PR for milestone 1.2.0 that I think will really update this repos testing capabilities and demonstrate just how much of the code can be tested. Will also take another back it to see if I can add anything more tests to those it was a pretty good overall I believe. This was because before we wouldn't test anything that uses the `vscode` api package but I was able to find a way that we could test that could now so some stuff needed refactored and a good bit of additional tests were added.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [daffodil-vscode] stevedlawrence commented on issue #270: PR Request VSIX Build and Upload

[GitBox <gi...@apache.org>]

stevedlawrence commented on issue #270:
URL: https://github.com/apache/daffodil-vscode/issues/270#issuecomment-1227474564

   > @stevedlawrence @mbeckerle How would you guys feel about something like this?
   Just want to clarify that neither Mike nor I have any more sway over decisions than any other member of the community. Any decisions should be made by, and addressed to, the Daffodil community, who are hopefully tracking new issues, especially those PMC/committers whose main focus is on the VS Code extension. I would love to hear from other committers on their thoughts as well.
   
   As to the question. I don't think I have anything against uploading vsix files as build artifacts, as long we don't promote these artifacts and make it clear that they are purely for snapshot dev purposes. These artifacts have not be reviewed or voted on, so cannot be treated the way one would treat a normal release artifact.
   
   As to the usefulness of this, I don't personally think I would find it useful, but I won't stand in the way if others do. If there's a PR that I want to test, I usually just check out the PR and build it. Building a vsix is a one liner, and is pretty quick. Especially considering vsix files are pretty large, approaching 200MB.
   
   I also think having an automated test infrastructure would alleviate some of this. Rather than downloading and manually testing a PR, instead we should be able to rely on tests being written for the PR and automatically run as part of the workflow. 
   
   Also, note that we definitely can't use this workflow for release candidates, since that needs to go through a separate review/vote process.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org