Re: Nba Action 98 Full Version
Golda Barocio
You can create actions by writing custom code that interacts with your repository in any way you'd like, including integrating with GitHub's APIs and any publicly available third-party API. For example, an action can publish npm modules, send SMS alerts when urgent issues are created, or deploy production-ready code.
You can build Docker container, JavaScript, and composite actions. Actions require a metadata file to define the inputs, outputs and main entrypoint for your action. The metadata filename must be either action.yml or action.yaml. For more information, see "Metadata syntax for GitHub Actions."
Docker containers package the environment with the GitHub Actions code. This creates a more consistent and reliable unit of work because the consumer of the action does not need to worry about the tools or dependencies.
A Docker container allows you to use specific versions of an operating system, dependencies, tools, and code. For actions that must run in a specific environment configuration, Docker is an ideal option because you can customize the operating system and tools. Because of the latency to build and retrieve the container, Docker container actions are slower than JavaScript actions.
Docker container actions can only execute on runners with a Linux operating system. Self-hosted runners must use a Linux operating system and have Docker installed to run Docker container actions. For more information about the requirements of self-hosted runners, see "About self-hosted runners."
JavaScript actions can run directly on a runner machine, and separate the action code from the environment used to run the code. Using a JavaScript action simplifies the action code and executes faster than a Docker container action.
To ensure your JavaScript actions are compatible with all GitHub-hosted runners (Ubuntu, Windows, and macOS), the packaged JavaScript code you write should be pure JavaScript and not rely on other binaries. JavaScript actions run directly on the runner and use binaries that already exist in the runner image.
If you're developing a Node.js project, the GitHub Actions Toolkit provides packages that you can use in your project to speed up development. For more information, see the actions/toolkit repository.
A composite action allows you to combine multiple workflow steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action. To see an example, check out "Creating a composite action".
If you're developing an action for other people to use, we recommend keeping the action in its own repository instead of bundling it with other application code. This allows you to version, track, and release the action just like any other software.
Storing an action in its own repository makes it easier for the GitHub community to discover the action, narrows the scope of the code base for developers fixing issues and extending the action, and decouples the action's versioning from the versioning of other application code.
If you're building an action that you don't plan to make available to others, you can store the action's files in any location in your repository. If you plan to combine action, workflow, and application code in a single repository, we recommend storing actions in the .github directory. For example, .github/actions/action-a and .github/actions/action-b.
To ensure that your action is compatible with GitHub Enterprise Server, you should make sure that you do not use any hard-coded references to GitHub API URLs. You should instead use environment variables to refer to the GitHub API:
If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's patch version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.
Under this release management approach, users should not be referencing an action's default branch, as it's likely to contain the latest code and consequently might be unstable. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.
Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. You must use a commit's full SHA value, and not an abbreviated value.
GitHub Marketplace offers tools to improve your workflow. Understanding the differences and the benefits of each tool will allow you to select the best tool for your job. For more information about building apps, see "About creating GitHub Apps."
For more information, we have several internal actions where all the versions are the same (coming from same repo). We move the versions at the same time and thought it would be convenient to have some way to specify this once.
However, in the rare case you actually need to specify a dynamic version on a GitHub Action (e.g. you want to exact same version for both an action and a pip package, or you're testing your own GitHub Action), you can use the jenseng/dynamic-uses action, like so:
There's some discussion from GitHub staff members on why steps.uses doesn't support expressions in If GitHub Actions ever does support expressions in steps.uses, someone will probably comment it there, so subscribe to that thread if you want updates.
Semantic versioning essentially allows all users of your actions to reference only the major version and profit from patches and new features as they are released. At the same time, your users need to manually update the reference on breaking changes as that would change the major tag.
If this for some reason doesn't satisfy your requirements, you could also think about always using the @main reference. This is generally not advised for public actions as changes might break your workflows, but in a controlled internal environment this might be fine.
It is hard to choose @tag or @master. If you select @tag, you will not be able to use the new features and bug fixes for that actions. If you select @master, you will worry about the latest code not being compatible with your earlier logic.
I'm an actions author, and created a major version tag v1. When new code is released, the new tag v1.0.x is created and I updated tag v1 with the new commit sha. In the Marketplace README.md, users are reminded to use @v1 to use compatible new features in a timely manner, and to use @v1.0.x to seek stability.
I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 2.1.3.4634 crashed", and I can figure out which source this was). I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).
However, in order to get the correct Build to appear in my Executable, I must build twice. The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.
Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this. I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build. True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?
The project configuration, which includes build info, is read when the project loads, so it's too late to set/get that at build time. I can't tell from your post, but it sounds like you're getting/setting the XML directly? That's generally a good way to run into problems since the XML content (and format) is meant for internal use only.
In LabVIEW 2014, I absolutely do use Set Build Specification Version, but by the time I do this (in the Pre-Build Action), it is too late. I guess I need to "amend" my Feature Request to say that when a Build starts, the Version information should be "re-read" (maybe with Get Build Specification Version?) to allow the User to issue a meaningful Pre-Build Action.
Here's the sequence: I have code, saved under Subversion or some other VCS. The code has a Revision/Build number that is specific to the code being built. I decide to build an Executable. The Pre-Build Action, provided with the Project Folder Path, figures out the current Build and puts that into the Version Information's "Build". Now the Build happens, and this code-specific number is embedded into the Executable (which doesn't have any obvious "attachment" to the Project location, which might be on another machine). Now I run the program, which does a FileVersionInfo and displays for me (the User) the Version Info. Wherever this Executable is deployed, it has the Version Information that includes build-time "links" to the actual code base. And it all happens automatically with LabVIEW.
I see. I was not clear on how you were getting/setting the version. That VI is definitely the way to go when getting/setting the build version, so I'm glad to hear you're using it, however, it wasn't designed for this use case where the version is being updated at build time. On the backend, that VI touches the project and build configuration saved in the XML, which has already been read into memory by the time you're building.
b1e95dc632