Hit an immediate roadblock attempting to use go-swagger (for the first time) with GitHub's REST API OpenAPI Descriptions.
All I want to do is generate Golang structs for GitHub Package. At this point, I may just continue muddling through hand-writing these structs using the example on that page as a guide.
I tried ghes-3.4:
REPO="https://raw.githubusercontent.com/github/rest-api-description/main"
PATH="descriptions/ghes-3.4/ghes-3.4.yaml"
podman run \
--interactive --tty --rm \
--volume=${PWD}/gh:/gh \
quay.io/goswagger/swagger generate client \
--spec=${REPO}/${PATH}
And received a wall of errors:
2022/03/28 16:51:42 validating spec https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/ghes-3.4/ghes-3.4.yaml
The swagger spec at "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/ghes-3.4/ghes-3.4.yaml" is invalid against swagger specification . see errors :
- .components in body is a forbidden property
- .openapi in body is a forbidden property
- .servers in body is a forbidden property
- "paths./repos/{owner}/{repo}/pulls/{pull_number}.get.responses.200" must validate one and only one schema (oneOf). Found none
...
And then tried api.github.com:
REPO="https://raw.githubusercontent.com/github/rest-api-description/main"
PATH="descriptions/api.github.com/api.github.com.json"
podman run \
--interactive --tty --rm \
--volume=${PWD}/gh:/gh \
quay.io/goswagger/swagger generate client \
--spec=${REPO}/${PATH}
And another wall of slightly different errros:
2022/03/28 16:54:15 validating spec https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json
The swagger spec at "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json" is invalid against swagger specification . see errors :
- .servers in body is a forbidden property
- .components in body is a forbidden property
- .openapi in body is a forbidden property
- paths./orgs/{org}/actions/permissions/selected-actions.put.requestBody in body is a forbidden property
go-swagger has good documentation but github.com/rest-api-description is lacking. Beyond being encouraged to use the 'bundled' descriptions, I'm assuming that the 3.4 in ghes-3.4 refers to the most recent version of Github's REST API bu t I'm unsure whether I should be starting with ghes-3.4 or api.github.com.
Related
I'm facing something new in my experience. An updated Yocto environment fails to build while fetching MariaDB:
WARNING: mariadb-5.5.64-r0 do_fetch: Failed to fetch URL https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz, attempting MIRRORS if available
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-BIEhFRRkoA"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/scripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin/arm-openstlinux_eglfs-linux-gnueabi:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot/usr/bin/crossscripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/bitbake/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/hosttools"; export HOME="/home/osboxes"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/downloads 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz' --progress=dot -v failed with exit code 8, output:
--2019-11-03 12:10:45-- https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving downloads.mariadb.org (downloads.mariadb.org)... 116.203.207.31, 2a01:4f8:c2c:b04e::1
Connecting to downloads.mariadb.org (downloads.mariadb.org)|116.203.207.31|:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz [following]
--2019-11-03 12:10:46-- http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving ftp.hosteurope.de (ftp.hosteurope.de)... 80.237.136.138, 2a01:488:10:1::50ed:888a
Connecting to ftp.hosteurope.de (ftp.hosteurope.de)|80.237.136.138|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-11-03 12:10:46 ERROR 404: Not Found.
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure for URL: 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz'. Unable to fetch URL from any source.
ERROR: mariadb-5.5.64-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/temp/log.do_fetch.11382
ERROR: Task (/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb_5.5.64.bb:do_fetch) failed with exit code '1'
Now I see the URLs are hardcoded into: layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb.inc:
SUMMARY = "A robust, scalable, and reliable SQL server"
HOMEPAGE = "http://mariadb.org"
SECTION = "libs"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
SRC_URI = "https://downloads.mariadb.org/f/${BP}/source/${BP}.tar.gz \
file://fix-cmake-module-path.patch \
file://remove-bad-path.patch \
file://fix-mysqlclient-r-version.patch \
file://my.cnf \
file://mysqld.service \
file://install_db.service \
file://install_db \
file://mysql-systemd-start \
file://configure.cmake-fix-valgrind.patch \
file://fix-a-building-failure.patch \
file://change-cc-to-cc-version.patch \
file://0001-disable-ucontext-on-musl.patch \
"
Hence, I tried to retrieve the same file (mariadb-5.5.64.tar.gz) on the Internet and I found this:
https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz/from/http%3A//ftp.hosteurope.de/mirror/archive.mariadb.org/?serve
that seems very close to the one above, but the working one has another path as suffix.
I don't understand if they (the mariadb maintainers) changed the URLs or there is an error in the meta-openembedded recipe.
The maintainers of FOSS software, in this case the MariaDB Foundation, usually don't make promises that download URLS will remain unchanged. MariaDB uses a scheme to help downloaders find a nearby mirror site, and that's what you found.
Those mirrorfinders rely on stuff like http redirect operations. Browsers are good at handling those operations. Downloading code built into other programs may not be.
You may find it helpful to edit that URL in that recipe to point to the exact ftp file you need. It appears to be in this ftp folder.
http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-5.5.64/source/
I want to hit an api (GET request) in clojure inside open shift pod with "no-proxy" but it gives me 404 (resource not found) although I passed correct header (for authorisation inside open shift pod). Same request giving 200 by curl command with noproxy in pod terminal. Please suggest.
Using Clojure API - clj-http.client
Below is Clojure code which is not working (giving 404):
(defn get-toggles []
(let [options {:headers {:x-jwt-payload "valid-value-passed"}}
response (client/get "correct-url" {:proxy-ignore-hosts "*" :proxy-port "*"} options)]))
Below is Curl hit inside pod terminal that is working fine (with noproxy only):curl -i --noproxy "*" "any-correct-url" -H "x-jwt-payload :valid-value"
Note: without "noproxy", we will get 401 thats why we are using it.
Looking at the source code, there seems no way to create a request that specifically uses no proxy at all.
I once ran into the same problem and ended up using Jsoup, a java library for making http requests and parsing HTML. I did not use the HTML parsing function, I sent requests to a Rest Api, but the Api of Jsoup is nice and well usable from Clojure. For example:
(ns something
(import
org.jsoup.Jsoup
java.net.Proxy
java.lang.Thread))
(defn api-call [url]
(->
(Jsoup/connect url)
(.proxy (Proxy/NO_PROXY))
(.ignoreContentType true)
(.get)
(.body)
(.text)))
The airflow documentation states:
Airflow exposes an experimental Rest API. It is available through the webserver. Endpoints are available at /api/experimental/. Please note that we expect the endpoint definitions to change.
https://airflow.apache.org/api.html#experimental-rest-api
However it doesn't state in which version the API appears. We are running Airflow v1.8.0
But whenever I browse to /api/ or /api/experimental/ I get a 404 and the spinning circles.
I tried curling the same URLs but that only confirmed the same, /api/ gives me a 404:
$ curl -I -L -s http://${AIRFLOWIP}:8080/admin/ | grep HTTP
HTTP/1.1 200 OK
$ curl -I -L -s http://${AIRFLOWIP}:8080/api/ | grep HTTP
HTTP/1.1 404 NOT FOUND
We have this setting in airflow.cfg:
[api]
# How to authenticate users of the API
auth_backend = airflow.api.auth.backend.default
I don't know whether the API is only available in a later version of Airflow or if we have stood it up incorrectly.
Can someone let me know in which version of airflow we can find the experimental API?
The first experimental endpoints were added in 1.8.0, with a few more endpoints added in following releases. There is no endpoint for the root paths of /api/ and /api/experimental/ on any version, so those curls are not expected to work. However, there is a /api/experimental/test/ endpoint which you can hit to confirm the API is available.
If you're going to be using the experimental API, I think the code is the best reference at the moment.
The Airflow API is no more at the experimental phase.
Stable version here Airflow REST API.
I'm trying to update the property of an artifact(In my case sample text file)
I tried the API https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-UpdateItemProperties
this is what I tried:
curl -X PATCH -uadmin:password -H '"props":{"ccs_x1_version":
"7.7.7.7"}'
"http://XXXXXXXXX:8081/artifactory/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
but was not successful, as command returns nothing, can someone help me in figuring out the right usage.
Looks like you're missing the API endpoint for using the UpdateItemProperties. You're also sending the data as malformed JSON as a header rather than data.
You need to add the endpoint: /api/metadata/ and reformat your data to a proper JSON.
{
"props" : {
"ccs_x1_version": "7.7.7.7"
}
}
According the the link provided:
Since: 6.1.0
Security: Requires a privileged user (Annotate authorisation required)
Usage: PATCH /api/metadata/{repoKey}/{itemPath}?[&recursive=1]
Produces: application/json
Sample Usage:
PATCH /api/metadata/libs-release-local/org/acme?[recursive=1]
{
"props":{
"newKey": "newValue",
"existingKey": "modifiedValue",
"toBeRemovedKey": null
}
}
If you update your request to curl -X PATCH -uadmin:password -d '{"props":{"ccs_x1_version": "7.7.7.7"}}' "http://XXXXXXXXX:8081/artifactory/api/metadata/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
This is also a new rest endpoint which is only available with the latest version of artifactory 6.1.0. If you're running an older version you're going to have to use the previous endpoint (Set Item Properties) in the official JFrog Documentation.
This is formatted curl -X PUT -uadmin:password "http://XXXXXXXXX:8081/artifactory/api/storage/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt?properties=ccs_x1_version=7.7.7.7"
Artifactory OSS
5.4.6 rev 50406900
Trying to get access token to work.
I created token...
e.g. curl -uadmin:adminpw -X POST "myserver:8081/artifactory/api/security/token" -d "username=moehoward"
Returned msg looks like success...
{
"scope" : "member-of-groups:readers api:*",
"access_token" : <very-long-string>
"expires_in" : 3600,
"token_type" : "Bearer"
}
I can see it in the gui (admin -> Security -> Access Tokens) with "Subject" = to the user ("moehoward" in the example above) and with a "Token ID" that's a lot shorter, something like...
f2eb693a-d4ff-4618-ba52-764dc975c497
To test, I tried to ping using example in the docs...
curl -umoehoward:<very-long-string> myserver:8081/artifactory/api/system/ping
Fails with a 401 (bad credentials).
I replace the token with the "token id" I see in the gui, same result.
I replace again with the hardcoded pw of the "moehoward" user and that works (responds with "OK").
I tried the "-H"Authentication: Bearer " approach using the long string and that worked. So I guess the very long string is the token and not the "Token ID" in the gui.
Q: Any idea why this works for Bearer" and not the user by name ?
So you are right that this is supposed to work for both standard authentication and the Authentication HTTP header.
I did the test on a server with the same version Artifactory OSS 5.4.6 and the following works fine here
Inject the proper variables
export SERVER=server-artifactory
export APIKEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Create and use an access token for user moehoward
curl -u "admin:$APIKEY" -X POST "http://$SERVER/artifactory/api/security/token" -d "username=moehoward" -d "scope=member-of-groups:readers" > token.log
export TOKEN=`cat token.log | jq -r '.access_token'`
curl -u "moehoward:$TOKEN" "http://$SERVER/artifactory/api/system/ping"
curl -H "Authorization: Bearer $TOKEN" "http://$SERVER/artifactory/api/system/ping"
I get "OK" from the last two commands. Can you run exactly these commands and report back?
I have personally experienced the same problem (Bearer header working, standard user credentials not working) with an old version of curl. The obvious workaround is to use Bearer, the more complex workaround is to upgrade curl (or use another tool).
What is the version of curl you use? Any curl from 2015 or more recent should work fine.