The github release resource allows us to set a version, but as far as I can tell, that just sets a floor on the version we'll accept: it will give us anything newer than that version.
We're looking for a way to accept versions based on semver positions. In our case, we want to ensure we don't automatically accept a major revision bump.
For example, we want the latest 4.x.x, but we don't want 5.anything.
We can achieve a similar effect using the git resource's tag_filter Source Configuration. We'd like a similar facility in github-release resource.
The github-release resource doesn't currently support this type of filtering based on tag versions.
Could you please submit an issue on the resource for this?
Related
I'm trying to figure out how to specify "Previous Tag" via queryparams in the release form automation, or via the Create Release API. Preferably Both.
Here is the feature in the UI documented as step 7 here.
If there is no way to do this - where does one request a feature for github? Ex: Is there a github project for github?
Here are the documentation pages for the two ways to do this:
Automation for release forms - there is no "previous_tag" option.
Create a release API - there is no obvious reference to how to specify previous tag, even though there is a way to specify and tell it to generate release notes.
To repeat the question one more time:
How do we specify the specify the prerelease tag for release note autogen? - if unavailable, where does one request a feature for github?
Update:
There is a separate API for generating the release notes, which accepts the previous_tag parameter.
For the querystring, a feature request is open in the github feedback board. Vote for it go give it visbility, hopefully GitHub will take note and implement it.
Original Answer:
It does not look like you can configure it via queryparameters or the API yet. The documentation you shared seems to confirm that.
GitHub has an open discussion board where you can propose features and they have previously shown that they work on topics that resound with the community.
I don't see a fitting category for "Releases" right now, but you can probably fit it into the categories APIs and Integrations or General.
GitHub has a public api that one can access to get current release info, and find the release file (.deb or .tar.gz or .exe, etc) by going to https://api.github.com/repos/[project creator]/[project]/releases/latest
Does GitLab have something similar? I'm working on an automated installer to get certain programs from GitLab that have releases. Using the above api for GitHub, I'm able to get the json info for the current release, and get the url to download the latest release, based on what version I want.
I'm hoping to find something similar in GitLab.
Look no further than GitLab's Release API Docs to start that investigation. It looks quite robust, and I believe you will find it can provide that information.
You can use this API to query for each project, looking for the releases it has. (You could also look for the availability of the project if you are unsure if it is present). Once found, determine the release to retrieve. It's important to note that releases are not always made by a team, so they hopefully are specifically packaging the code into a release for distribution. Additionally, via the API, you can also ensure that the release has specific tags so that if they are using tags, you can focus on specific ones of note, or you can use a more generic approach (e.g. semantic version) to determine which release to retrieve.
Hope that helps. GitLab has a rich API. Take a look.
I am using Open API 3.0 specification to document my APIs.
I have observed that Open API 3.0 has a version attribute. I was wondering if it had a way to document changelogs. Or do just use the externalDocs attribute ?
Changelogs are not a built in feature of the specification but the version field definitely helps as the basis for generating them. I've got a GitHub action that does a "release" on GitHub when a specification version number changes (which is does for every change we make) so the releases page becomes our changelog. The data can also be taken from the releases (available via GitHub API).
As for pointing to a changelog - externalDocs is probably a good way to do it.
In Azure DevOps :
We have a build pipeline, configured through the GUI editor.
I would like to share a link with my colleagues which points to a precise revision of this build pipeline
("sharing with my colleagues" = mention it in our internal issue tracker)
Question
Is there a way (through devop's GUI) to view the state of a build pipeline at a given revision?
A way with a shareable url?
I don't think you can show a precise revision of a build definition in the UI without to revert to this revision. you can see a revision of the build in a JSON format. if you go to "History" Tab and compare the difference between versions:
You will get a screen with the current version and the other (in JSON).
The URL in the comparison page is also unique to this comparison so you can share it.
Another option is to use the Rest API to get the precise revision, but also only in JSON format:
https://dev.azure.com/shaykia/{project-GUID}/_apis/build/Definitions/{build-id}?revision={revision-id}
The above call returns a JSON of specific revision, you can also share it.
(You can get all the revisions with Get Definition Revisions API).
I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.